Requirements for Object Management in Software

syntax trees, relationships, as well as the basic types like Booleans, integers and strings. It should allow the environment builder to de ne new types and modify existing types. All the three surveyed systems have prede ned types and support de nitions of other types. In the remainder of this section, we concentrate on issues related to the modi cation of existing types. The object types in a software engineering environment may change in time due to changes in requirements. New types may also be added to the type model, and existing types may be changed. Addition of new types does not pose problems, whereas modi cation of existing types does. This is because there may be data associated with the existing types and modifying the type de nitions could make the data potentially unreadable. Objects associated with old types thus need to be migrated, to make the object base consistent with the new type de nitions. This is known as schema evolution. The two primary update mechanisms for schema evolution are immediate and lazy updates. In immediate updates, data migrates to conform to the new type de nitions as soon as the type de nitions are changed. Thus all running applications must be suspended until the entire object base is brought to a consistent state. With lazy updates, however, the objects are updated only when they are accessed. As such, lazy updates need to maintain possibly the entire evolution history. In general, both update mechanisms are required and the user should be able to choose dynamically between the two approaches. A problem associated with schema evolution is the speci cation of transformation functions from old types to new types. These functions are used to transform objects of old types to be consistent with the new type de nitions. In some cases it may be possible for the system to generate the transformation functions automatically, whereas in other cases the environment builder's intervention is required. The object management system should provide means for the builder to specify transformation functions, where an automatic generation of transformation function is not possible. As mentioned earlier, only the environment builder may be allowed to modify existing types. Hence type evolution is a requirement primarily relevant to the builder. The object management system should allow the builder to specify the transformation functions for mapping old types to new types. The builder should also be able to specify that the modi cation of a particular type takes a lazy or immediate approach. The user may on the other hand be able to overwrite lazy update with an immediate update for a given type. However the user may not overwrite an immediate update with a lazy policy. The type evolution software system (TESS) developed in the Arcadia research environment supports automatic type evolution [17]. The type changes are identi ed by examining the editing results. Type de nitions are then compared to identify the mappings from old types to new types. In the situations where fully automatic generation of transformation functions are not possible, semi-automated assistance is provided. Lazy updates are preferred in Goodstep, mainly because unlike immediate updates, lazy updates do not require applications being suspended. However the strategies for implementing lazy updates are more complex. In Goodstep, the problems associated with using complex conversion functions during lazy updates have been identi ed and certain techniques for implementing schema updates have been proposed [12, 11]. Simple conversion functions are the ones that only involve data local to the type concerned, whereas complex conversion functions are the ones that involve data from other types. All the algorithms proposed for lazy updates are based upon keeping the history of the entire schema evolution in terms of class descriptors. The attributes and methods associated with the class at each phase are kept and the conversion functions will use this kept history to update the class 11 in the next phase of the schema evolution. 3.9 Distribution Several users may access the object base via di erent workstations. The object management system should provide an access mechanism that allows such distributed access of the object base. The distribution mechanism may take an client-server approach or a distributed object base approach. The client server approach is a centralised approach as the data exists on the server and is accessed by the various client stations. The disadvantage of this approach is that the server may become the bottleneck. In the distributed object base approach, the data is distributed transparently across several workstations. It is desirable for the object management system to provide a facility that enables the environment builder to choose between the two approaches, depending on the application domain. Though the users need not know the physical distribution of objects, it should be possible for the environment builder to specify the location of objects or to relocate objects in the distributed object base for e ciency purposes. The current version of Pleiades does not address distribution which is suggested as a future enhancement. Goodstep has adopted the client-server approach. PCTE supports teamwork through distributed network architectures. It allows data access to be carried out without regard to the physical location of the data, either from the tool's or the user's point of view. Some speci c mechanisms are also provided for the object base administrators to re-group objects, in order to improve the distribution of data for performance reasons. 3.10 Views The users and tools of a software engineering environment may not need to access all objects. A tool may for example be only concerned with some objects of the object base. They may manipulate these objects by adding or hiding attributes or de ning new operations on the objects. View de nition makes the above activities feasible without involving all the objects. Views are usually de ned by selecting the object types concerned. The object management system should provide a facility for creating and managing views in the object base. Other issues that need to be dealt with are related to persistence of views, change migration from views to underlying objects, and change migration from underlying objects to related views. The environment builder may be the only one allowed to specify views, since views are based on types which can only be speci ed by the builder. The builder may also provide some generic view types, which can be somehow customised by the user. Goodstep proposes a view mechanism based on virtual schemas [1, 24]. A virtual schema de ning a view is derived from a root schema which can be a real or virtual schema, and contains de nitions of classes, methods, types and functions. It may use virtual classes, imaginary classes and virtual attributes, and hide properties. The essence is to import data (i.e., attributes as well as methods) from the root schema and formulate a view through rede nition and hiding. It should be noted that a real schema cannot import de nitions from a virtual schema. PCTE users and tools can select their working schema as a union of schema de nition sets that are known to the object management system. With this approach, it is possible to hide nodes and edges from particular tools and to rename node and edge types. Updates made through these views migrate to the underlying object base. 12 According to the available literature, Pleiades does not support any explicit view mechanism. Neither is view support a requirement for Triton. 3.11 Resource Management Software engineering environments may involve many hardware and software resources. They may include various software tools such as compilers, editors and debuggers, and hardware resources like workstations and printers. The object management system should provide a facility to model these resources as objects and provide a mapping between the object representation of the resources and the actual resources. This makes it feasible to grant or refuse access to certain tools or hardware from within a software engineering environment by de ning access rights on the object representation. Modelling of resources allows the environment builder and the project manager to add or remove resources and to de ne a suitable resource management policy from within the environment. A user may for example have access to a certain resource in one project but may not have the same access right in another project (assuming each project has its own environment). The above strategy makes the modelling of such situations feasible. Resources in PCTE include tools, services and physical devices installed. The tools and services are represented by static contexts in the object base and are accessible from any connected workstation, subject to access and visibility control. The physical devices are also represented in a similar manner. Goodstep and Arcadia do not address this issue of resource management, though hints in the literature suggest a possible area of future investigation. 3.12 Version Control and Con guration management Objects in a software engineering environment need to be versioned and con gured. Version control is concerned with the evolution of a single or composite object, while con guration management is concerned with a set of individual versions of objects. A con guration in a software engineering environment is the collection of objects relevant to a speci c purpose such as a deliverable product or a baseline. It is not necessary to enumerate the requirements for version control and con guration management in this paper, since they have been dealt with extensively in the literature. But the object management system should provide the necessary operations to implement any version control or con guration management policies. For example, it should be possible to create successors of an object to make a new version, to name a version or to de ne a composite object. Operations such as branching snapshot and baselining should also be supported. In general, the software engineering environment should not enforce a particular version control or con guration management policy. Instead, the environment builder should be able to codify such a policy. The environment user adheres to the policy and uses functions provided by the environment builder. PCTE allows versioning of objects. It does not dictate a particular naming policy for versions, but one can be de ned that is suitable for a particular application. Versioned objects are created via predecessor-successor relationships. Two possible operations are snapshot and revise. A snapshot creates a copy of the object: the original object remains modi able, but the snapshot is stable. A predecessor-successor relationship is created between the two objects. Revise on the other hand makes a modi able version of the object and stabilises the original object. It also creates a predecessor-successor relationship be13 tween the two. PCTE does not de ne any speci c con guration management operations of its own. However a con guration management policy can be implemented on top of PCTE using composite objects. (By default, an object in PCTE is considered composite. A primitive object is an object that does not have any components, and can evolve into a composite object by introducing composition links to its components.) Goodstep proposes a version manager that can be built on any object database system supporting composite objects [23]. The granularity of versioning is that of composite objects. The operations of the version manager include create, derive, freeze, update and delete. Version control and con guration management are not yet addressed in Pleiades or Triton. 3.13 State Information It should be possible to determine the state of any object at any time. For example, it should be possible to determine whether a document has been formatted, syntax checked or spell checked. The object management system may be required to provide a model for maintaining the state information associated with the various objects. This state information may also prove useful for other requirements such as consistency checking. Because the state information is associated with the objects and is persistent, it should be stored and managed by the object management system. In general, the state information can be modelled via attributes of the objects. Since Pleiades, Goodstep and PCTE allow speci cation of object attributes, state information can easily be maintained in these systems. 3.14 Backup Mechanisms The object management system should provide means to backup the object base. This may be done automatically or manually. The environment builder should be able to specify the frequency of backups. The user on the other hand may choose whether any objects should be ignored for backups. Besides, the user should be able to force an immediate backup in situations where the user feels that a critical portion of work has been carried out. A policy for backup may be speci ed by the environment developer. The environment builder may have limited control on this backup mechanism by specifying certain parameters such as frequency or objects to be ignored for backups. This issue again has not been addressed explicitly in the surveyed systems, especially from the builder's perspective. 3.15 ODL and OML The object management system should provide a complete and strongly typed object de nition and manipulation language (ODL/OML) that facilitates de nition, update and management of types, objects and relationships. The schema de nition language in Pleiades is based on ADA while Triton uses E 2. In Goodstep O2 data de nition language is used. In general, a need exists to provide an ODL/OML that makes it convenient for the environment builder to specify project speci c requirements. 2E is the persistent programming language for Exodus. 14 SE Tools / EnvironmentsOODBMSO M SFigure 1: The use and the conceptual architecture of an OMS4 Conclusions and Future WorkIn this paper, we have presented a comprehensive set of requirements for object managementin software engineering tools and environments. We have also attempted to summarise howGoodstep, Arcadia and PCTE meet these requirements. It is obvious that none of thesystems satisfy all the requirements. Further investigation is required to achieve e ectiveobject management in software engineering tools and environments, especially in the areasof object representation, relationships, consistency management, persistence and advancedtransactions.As future work, we plan to develop an object management model and a correspondingobject management system that meet the major requirements identi ed in this paper. Theuse and the conceptual architecture of the envisaged object management system are depictedin Figure 1. It wouldfacilitate the general database features required through an object oriented databasemanagement system (OODBMS), andprovide specialised and higher level features for the environment builder to use, someof which may be implemented on top of the OODBMS.Such an object management system will be able to overcome the problems associated withthe direct use of an object database management system (see section 1). The builder of asoftware engineering tool (or environment) will be able to use a high level language to de nethe tool's speci c requirements for object management, and implement the tool's function-ality based on the support provided by the object management system. The provision ofsuch an object management system will signi cantly ease the burden of developing soft-ware engineering tools and environments, and provide the much needed support for objectmanagement in these tools and environments in an e ective manner.15 References[1] S. Abiteboul, C. Santos, and C. Delobel. Virtual schemas and bases. In Proceedings ofthe EDBT (Extending Database Technology) '94, volume LNCS. Springer, 1994.[2] R. Balzer. Tolerating inconsistency. In Proceedings of 13th International Conferenceon Software Engineering(ICSE-13), pages 158{165, Austin, TX, USA, May 1991.[3] F. Bancilhon, C. Delobel, and P. Kanellakis. Building an Object Oriented DatabaseSystem: The Story of O2. Morgan Kaufmann Publishers, 1992.[4] P.A. Bernstein. Database system support for software engineering. In In Proceedingsof 9th International Conference on Software Engineering, Monterey, California, pages166{178, 1991.[5] E. Casais, M. Ranft, B. Schiefer, D. Theobald, and W. Zimmer. OBST | an overview.Technical Report FZI.039.1, FZI, Karlsruhe, June 1992.[6] C. Collet, T. Coupaye, and T. Svensen. NAOS e cient and modular reactive capabil-ities in an object-oriented database system. In Proceedings of the 20th InternationalConference on Very Large Databases, Santiago, Chile, September 1994.[7] C. Collet, P. Habraken, T. Coupaye, and M. Adiba. Active rules for the softwareengineering platform goodstep. Technical Report 10, ESPIRIT-III Project GoodStep(6115), December 1993.[8] W. Emmerich. Tool Construction for Process Centered Software Development Envi-ronments Based on Object Database Systems. PhD Thesis, University of Paderborn,Germany, 1995.[9] W. Emmerich, P. Kroha, and W. Schafer. Object oriented database managementsystems construction of CASE environments. In Proceedings of the 4th InternationalConference on Databases and Expert Systems Applications (DEXA 93), volume LNCS,pages 631{642, Prague, Czech Republic, 1993. Springer.[10] W. Emmerich, W. Schafer, and J. Welsh. Databases for software engineering environ-ments { the goal has not yet been attained. In Proceedings of the 4th European SoftwareEngineering Conference, volume LNCS, pages 145{162, Garmish-Partenkirchen, Ger-many, 1993. Springer.[11] F. Ferrandina, T. Meyer, and R. Zicari. Implementing lazy database updates for anobject database system. In Proceedings of the 20th International Conference on VeryLarge Databases, Santiago, Chile, 1994.[12] F. Ferrandina and R. Zicari. Object database schema evolution: Are lazy updatesalways equivalent to immediate updates. In OOPSLA Workshop on Supporting theEvolution of Class de nitions, Washington, DC, USA, September 1993.[13] J. Han. Software documents, their relationships and properties. In In proceedings of1994 Asia-Paci c Software Engineering Conference, Tokyo, Japan, December 1994.16 [14] Dennis Heimbigner. Experiences with an object manager for a process-centered envi-ronment. In Proceedings of the 18th VLDB Conference, Vancover, British Columbia,Canada, Aug 1992.[15] R. Kadia. Issues encountered in building a exible software development environment:Lessons from the arcadia project. In Proceedings of the Fifth ACM SIGSOFT Sympo-sium on Software Development Environments (SDE5), pages 169{180, Dec 1992.[16] D.E. Knuth. Semantics of context-free languages. Mathematical Systems Theory,2(2):127{145, 1968.[17] Barbara Staudt Lerner. Type evolution support for complex type changes. Tech-nical Report 94-071, Department of Computer Science, University of Massachusetts,Amherst, USA, 1994.[18] C. Lewerentz and A. Schurr. Gras { a management system for graph like documents. InProceedings of the 3rd International Conference on Data and Knowledge Bases, pages19{31, 1988.[19] D. Maier. Making database systems fast enough for CAD applications. Object-OrientedConcepts, Database and Application, pages 573{582, 1989.[20] C. Morgan, K. Robinson, and P. Gardiner. On the re nement calculus. TechnicalMonograph PRG-70, Oxford University Computing Laboratory, Oxford, England, Oc-tober 1988.[21] N. Narayanaswamy and N. Goldman. Lazy consistency: A basis for cooperative soft-ware development. In Proceedings of International Conference on Computer SupportedCooperative Work (CSCW 92), pages 257{264, Toronto, ON, Canada, Oct/Nov 1992.[22] S. Popovich and G. Kaiser. An architectural survey of object management systems.International Journal of Intelligent and Cooperative Information Systems, 1(3 and4):515{577, 1992.[23] S. Sachweh and W. Schafer. Version management for tightly integrated software en-gineering environments. Technical Report 22, ESPIRIT-III Project GoodStep (6115),July 1994.[24] C. Santos. Design and implementation of an object oriented view mechanism. TechnicalReport 7, ESPIRIT-III Project GoodStep (6115), March 1994.[25] Peri Tarr and Lori A. Clarke. PLEIADES: An object management system for softwareengineering environments. In ACM SIGSOFT 1993 Symposium on Foundations ofSoftware Engineering, Los Angeles, USA, December 1993.[26] Richard N. Taylor, Frank C. Belz, Lori A. Clarke, Jack C. Wileden Leon Osterweil,Richard W. Selby, Alexander C. Wolf, and Michal Young. Foundations for the arca-dia environment architecture. In Proceedings of SIGSOFT88: Third Symposium onSoftware Development Environments, pages 1{13, Nov 1988.[27] The GoodStep Team. General object-oriented database for software engineering pro-cesses. In Proceedings of 1994 Asia-Paci c Software Engineering Conference, Tokyo,Japan, December 1994.17 [28] L. Wakeman. PCTE: The Standard for Open Repositories. Prentice Hall, 1993.[29] J.C. Wileden, A.L. Wolf, C.D. Fisher, and P.L. Tarr. PGraphite: An experiment inpersistent typed object management. In Proceedings Third ACM SIGSOFT/SIGPLANSymposium on Practical Software Development Environments, pages 130{142, Nov1988.[30] R. Zicari and C. Bauzer-Meideros. New generation database systems. In ConceptualModeling, Databases and CASE { An Integrated View of Information Systems Devel-opment. John Wiley, 1992.18